With the maturity of the Multi-Protocol Label Switching (MPLS) related standards and the popularization of the network multimedia applications, such as IPTV and videoconference, multicast technologies are applied to support the point-to-multipoint and multipoint-to-multipoint communications in a MPLS network, which has become an effective technical method for reducing bandwidth consumption and improving the Quality of Service (QoS).
In the conventional MPLS multicast application solution, a Label Switched Path (LSP) can be established in two ways: (i) a downstream node sends a label mapping to an upstream node to establish a LSP; or (ii) an upstream node receives a request of joining a multicast group from a downstream node, and allocates a label to the downstream node to establish a LSP. The two conventional methods are elaborated below with reference to the accompanying drawings.
As shown in FIG. 1, in a MPLS domain, an egress node is directly connected with the multicast receiving user node, for example, the R6 node shown in FIG. 1; and an ingress node is directly connected with the multicast source, for example, the R0 node shown in FIG. 1. A multicast data stream enters a MPLS domain from an ingress node (R0), passes through intermediate nodes R3 and R5 along the route, and is sent by the egress node (R6) to the multicast receiving user. The method, in which a downstream node sends a label mapping message to an upstream node to establish a LSP, includes the steps as described below.
Step 1: The egress node R6 sends a local label mapping message to the upstream node R5 with respect to a multicast stream.
Step 2: The intermediate node R5 sends a local label mapping message to the upstream node R3.
Step 3: R3 sends a local label mapping message to the upstream node R0 (namely, the ingress node).
Through the previous steps, a LSP (R0->R3->R5->R6) is established for the multicast stream from an ingress node to an egress node.
As shown in FIG. 2, R6 is an egress node, and R0 is an ingress node. A multicast data stream enters a MPLS domain from an ingress node (R0), passes through intermediate nodes R3 and R5 along the route, and is sent by the egress node (R6) to the multicast receiving user. Alternatively, a multicast LSP may also be established through allocating, by the upstream node, a label to the downstream node actively, and this method includes the steps as described below.
Step 1: After receiving a request of joining a multicast stream receiving sequence from an ingress node R6, the ingress node R0 allocates a label to the downstream node R3 with respect to the multicast stream.
Step 2: The R3 allocates a label to the downstream node R5.
Step 3: The R5 allocates a label to the downstream node R6 (namely, egress node).
Through the previous steps, a LSP (R0->R3->R5->R6) is established for the multicast stream from an ingress node to an egress node.
As described above, all the conventional methods for establishing a multicast LSP in a MPLS domain require that the egress node directly connected with the multicast receiver must know the location of the ingress node before being able to establish a multicast LSP for a multicast stream. In other words, when establishing a conventional multicast LSP in a MPLS domain, a mapping relationship is statically preset between the multicast source and the multicast group on the egress node; otherwise, the egress node is unable to know the location of the ingress node or establish a multicast LSP between the ingress node and the egress node. With the application of the multicast services, such as IPTV, multi-party video conference, tele-education, and tele-consultation, it is necessary to configure every mapping relationship and maintain the network topology in order to statically configure a mapping relationship between the multicast source and the multicast group. The rapid growth of the multicast service requires maintenance of plenty of network topologies, which leads to higher and higher cost of maintenance. Meanwhile, the mapping relationship configured statically between the multicast source and the multicast group is unable to meet the requirements of on-demand dynamic development trend of multicast services.
Moreover, the mapping relationship configured statically between the multicast source and the multicast group is not conducive to multicast access control (for example, access license, bandwidth control, and priority setting). Only simple mapping is performed between the multicast source and the multicast group, without attaching the information on multicast access control policies to the mapping relationship. Therefore, the prior art is unable to control multicast access in the process of establishing a LSP.